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SECTION  1.  INTRODUCTION 


1.1  Purpose 

The  puipose  of  the  model  application  support  package  (ASP)  is  to  provide  information  about  the 
Amphibious  Assault  Model  (AAM)  for  use  in  future  studies  conducted  by  Studies  and  Analysis 
Division  of  the  Marine  Corps  Combat  Development  Command  (MCCDC).  Accreditation  of  a 
model  requires  an  asse|sment  of  the  specific  application  to  determine  the  suitability  of  the  model 
to  the  intended  purpose.  While  this  ASP  was  developed  in  support  of  an  accreditation  process, 
it  was  decided  that  it  would  be  useful  to  isolate  the  generic,  vice  application  specific,  information 
about  the  model  in  a  separate  document  so  that  others  considering  the  appropriateness  of  the 
model  to  another  application  might  find  this  compiled  information  useful  and  time  saving. 

1.2  Scope 


This  document  describes  the  AAM  using  the  modeling  taxonomy  for  warfare  simulation,  entitled 
SIMTAX,  that  was  developed  during  a  series  of  Military  Operations  . Research  Society  (MORS) 
workshops  in  1986  and  1987.  SIMTAX  was  pubUshed  by  MORS  and  distributed  by  the  Joint 
Staff  (J8)  as  a  part  of  their  1989  catalog  of  models. 


Section  2  describes  the  19  October  1994  configuration  baseline  of  AAM.  This  is  accomplished 
with  a  simplified  description  of  AAM  and  a  brief  summary  of  its  development  history.  The 
model  design  used  to  simulate  a  vertical  amphibious  assault  is  described  in  section  3  with  the  use 
of  some  simplified  logic  flowcharts.  This  includes  a  description  of  the  entities  modeled  and  the 
interactions  among  them.  This  is  typically  referred  to  as  the  model’s  "engine."  A  discussion  of 
the  model  assumptions  is  provided  as  well  as  the  implications  of  the  model  design  and  its 
limitations. 


The  Marine  Corps  Advanced  Amphibious  Assault  Vehicle  Supplemental  Analysis  (AAAV/SA) 
Accreditation  Team  was  primarily  interested  in  evaluating  surface  assault  system  alternatives. 
AAM  had  to  be  modified  to  be  suitable  for  use  by  the  AAAV/SA  analysts.  Appendix  A  contains 
a  description  of  the  conceptual  logic  changes  made  to  AAM  in  order  to  use  the  model  to  simulate 
a  surface  assault.  Appendix  B  lists  the  AAM  event  names  and  descriptions.  Appendix  C 
contains  a  detailed  list  of  the  characteristics  and  state  variables  for  each  of  the  AAM  entities. 
Appendix  D  lists  and  defines  the  acronyms  used  in  this  document. 


SECTION  2.  AAM  CONFIGURATION  BASELINE 


'  The  AAM  baseline  described  in  this  ASP  is  based  on  the  model  source  code,  annotated  with 
comments,  which  was  made  available  on  19  October  1994  to  the  AAAV/SA  Accreditation  Team. 
Evaluating  the  AAM  configuration  baseline  required  a  thorough  review  of  the  available  source 
documents,  and  interviews  with  BDM  employees,  to  describe  how  the  model  works,  how  the 
model  was  developed,  how  changes  to  the  model  are  processed  and  controlled,  and  what  user 
support  functions  are  available,  if  any.  This  section  of  the  ASP  also  summarizes  the  fundamental 
assumptions  and  limitations  of  AAM. 


2.1.  Model  Description 


The  AAM  is  an  event-driven,  Monte  Carlo  model  of  amphibious  operations  which  is  designed 
to  provide  insights  into  alternative  tactics,  doctrine,  and  equipment  that  can  be  used  to  perform 
vertical  and  surface  amphibious  assaults,  shore-to-shore  vertical  assaults,  and  general  off-load 
operations,  under  a  set  of  scenario-dependent  constraints. 

Originally  built  to  support  the  U.S.  Marine  Corps  in  evaluating  the  vertical  assault  capabilities 
of  different  mixes  of  heavy-  and  medium-lift  helicopters  and  tilt-rotor  aircraft,  the  AAM  is  well 
suited  to  the  analysis  of  even  the  most  heavily  constrained  airlift  problems.  Unlike  a  capacity 
or  tormage-based  methodology,  AAM  requires  the  analyst  to  construct  a  "load  plan,"  describing 
each  aircraft  or  ship  load  in  detail,  including  the  origination  point  (i.e.,  a  specific  ship)  and  the 
destination  on  the  beach.  Since  in  reality  it  is  a  rare  occurrence  for  a  transport  craft  to  reach  its 
capacity  in  tonnage  or  volume  when  carrying  a  military  load  (due  to  palletization  and  the 
outsized  nature  of  large  items),  the  load  plan  approach  provides  a  more  realistic,  operational 
assessment  of  movement  requirements  and  capabilities.  AAM  is  capable  of  modeling  multiple 
beaches  and  landing  zones  (LZs),  with  the  ability  of  landing  in  the  LZ,  then  moving  to  a  beach, 
or  subsequent  objective. 

A  number  of  the  aspects  of  an  amphibious  assault  which  may  have  random  effects  are  included 
in  the  calculations.  Break  and  repair  rates,  as  weU  as  attrition  due  to  enemy  fire,  are  modeled 
as  stochastic  processes.  AAM  typically  is  run  for  multiple  (e.g.,  100)  repetitions  to  measure  the 
expected  value  of  these  random  effects,  as  weU  as  the  range  of  uncertainty  of  the  problem  being 
studied.  It  is  a  relatively  small  model  written  in  approximately  3,200  lines  of  FORTRAN  code: 

2.2  Development  History 

AAM  was  developed  by  BDM  to  simulate  the  movement  of  troops  and  equipment  ashore  during 
an  amphibious  assault.  The  model  as  originally  designed  was  intended  to  model  the  vertical 
assault  portion  of  an  amphibious  assault.  The  model  is  a  time  scheduled,  calendar-driven  model. 
For  the  most  part  it  is  a  determistic  model;  however  it  contains  two  stochastic  elements.  The 
first  is  the  attrition  of  landing  platforms  and  the  second  is  the  breakdown  and  repair  of  landing 
platforms.  There  is  no  explicit  accounting  for  geometry  (i.e.  geometric  coordinates)  and  terrain 
or  sea  features. 
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Configuration  Management  and  V&V  Histor: 


All  model  runs  for  a  specific  study  are  made  with  a  single  version  of  the  model.  The  study 
version  of  the  model  and  all  input  data  files  are  archived  and  stored  for  approximately  five  years 
to  ensure  that  additional  investigation  of  study  results,  if  necessary,  will  be  consistent  with  the 
initial  model  runs.  This  means  that  the  model  is  closely  controlled  by  BDM’s  A  AM  software 
engineer  and  primary  analyst,  Mr.  E.  Bitinas.  BDM  conducted  a  systematic  walk  through  of  the 
model’s  design,  operation,  and  test  procedures  with  the  AAAV/SA  Accreditation  Team. 

BDM  uses  a  standard  configuration  rtianagement  procedure  that  has  been'+^applied  to  AAM. 
Changes  to  any  model  for  a  specific  study  are  implemented  and  tested  with  oversight  (two  levels 
of  oversight  when  practical).  Soiuce  code  changes  to  AAM  are  made  only  by  Mr.  E.  Bitinas, 
after  approval  by  Mr.  M.  Ellis  (BDM  Vice  President  for  Systems  Analysis).  Changes  to  the 
model  are  documented  by  comments  in  the  source  code. 

The  history  of  the  model’s  usage,  any  previous  verification  and  validation  (V&V)  that  has  b^n 
conducted,  its  configuration  management,  and  any  endorsements  are  considered  the  credentials 
of  the  model.  The  AAM  has  never  been  formally  verified  or  validated.  Table  2-1  contains  a  list 
of  studies  which  were  supported  by  AAM. 

2.4  Documentation 

The  only  model  documentation  available  from  BDM  was  a  comment-annotated  source  code.  A 
copy  of  the  code  was  provided  to  the  Accreditation  Team  by  BDM  on  19  October  1994. 


Table  2-1.  Previous  Studies  Using  AAM 


attain 

CUStlMMgatAGEUcy 

•  RtlSRDSg- •  •  • 

MLR  Cost  and  Operational  Effectiveness 
Analysis  (1994) 

Assistant  Secretary  of 
the  Navy  for  Acquisition 

Four  alternative  aircraft  were  compar^  in  a  variety 
of  tactical  combat  and  logistics  situations. 

MLR  Alternatives  Comparison  (1993) 

Boeing  Helicopter 

Various  MLR  alternatives  were  compared  in  a 
variety  of  tactical  situations. 

•V-22  EMD  Sceh^o,  Development  (1993) 

Boeing  Helicopter 

Provided  a  landing  sch^ule  for  a  vertical  assault  to 
be  used  in  the  EMD  trade  studies.  AAM  results 
were  used  to  calibrate  Boeing  and  Bell  models. 

.  AAAV  Alternative  Block  Upgrade  Options 
Analysis  (1992) 

General  Dynamics 

Land  Systems 

Assessed  the  value  of  upgrades  to  the  AAV, 
including  water  speed,  land  speed  armor  and 
armament,  in  a  Korean  scenario. 

V‘22  Operational  Effectiveness  (1988/89) 

Boeing  Helicopter 

Compared  the  V-22  with  other  helicopter 
alternatives  in  an  Iranian  scenario. 

Mine  Clearing  Requirements  Analysis 
(1987) 

USMC  MCCDC 

Established  the  mine  clearing  levels  for  sea, 
shallow  water,  surf  and  beach  mines  to  allow  the 
USMC  to  conduct  a  survivable  surface  assault. 

V-22  Effectiveness  Comparison  (1986/87) 

Boeing  Helicopter 

Compared  the  V-22  with  other  alternatives  in  a 
Norwegian  scenario. 

Ship  to  Shore  Mission  Area  Analysis 
(1987) 

USMC  MCCDC 

Assessed  the  ability  of  the  USMC  to  conduct 
amphibious  operations,  both  vertical  and  surface 
assaults  in  a  Pacific  scenario. 

SECTION  3.  MODEL  DESIGN 


The  model  design  is  described  in  a  table  and  a  series  of  figures  defining  the  conceptual  logic 
flow  of  the  model.  First,  the  "entities"  being  modeled  are  described.  These  aie  the  players  in 
the  simulation.  Their  capabilities  to  act  are  defmed  by  general  and  unique  characteristics.  Next, 
a  top-level  view  of  the  AAM  conceptual  logic  for  a  vertical  assault  is  presented.  The  next  three 
figures  describe  the  conceptual  "engine"  behind  the  model,  i.e.,  these  figures  describe  how  the 
AAM  entities’  actions  and  interactions  are  simulated  and  how  the  records  of  the  interaction 
outcomes  are  maintained.  A  summary  description  of  the  input  and  output  data  also  is  provided. 
This  section  of  the  AAM  ASP  concludes  with  a  listing  of  the  detailed  assumptions  used  in  the 
mo&el,  as  well  as  a  listing  of  the  limitations  of  the  model.  As  mentioned  earlier,  the  AAAV/S  A 
analysts  were  interested  in  using  AAM  for  assessment  of  surface  assault  alternatives.  Appendix 
A  contains  a  description  of  the  changes  to  the  AAM  conceptual  logic  flow  that  were  required  to 
simulate  a  surface  assault. 


3.1  Entities  Modeled 

Table  3-1  contains  a  list  of  the  major  entities  used  in  the  AAM  for  a  vertical  assault  simulation. 
A  more  detailed  description  of  the  entity  characteristics  and  state  variables  is  contained  in 
section  3.4,  which  covers  the  input  data  required  for  an  AAM  simulation  run,  and  in  appendbc 
C.  The  purpose  of  this  table  is  to  facilitate  the  discussion  of  the  model  conceptual  logic 
flowcharts  in  figures  3-1  through  3-4. 


Table  3-1.  AAM  Vertical  Assault  Entities 


eJTlTYtTELE  1  . . 

Helicopter  Types 

Characteristics  of  each 

Status  (e.g.,  availability,  attrition,  fuel  remaining,  etc.) 

Location 

Ships 

Number  of  landing  spots  on  flight  deck 

Helicopter  fuel  aboard 

Number  and  types  of  loads 

Loads 

Time  scheduled  to  be  at  the  beach 

Characteristics  (e.g,.  weight,  CPI,  personnel) 

Helicopter  type  needed  to  lift  load 

Number  of  subloads 

Subloads 

Land  vehicle  characteristics  (e.g.,  speed,  weight,  CPI,  personnel) 

Rendezvous  Points  (RPs) 

Several  RPs  may  be  defined 

Organizes  assault  wave(s)  for  LZs 

Landing  Zones  (LZs) 

Destination  of  Loads  (not  subloads) 

Number  and  size  of  landing  spots 

Each  LZ  can  have  no  more  than  one  beach 

Beaches 

Destination  of  subloads 

Forward  Arming  and  Refueling  Point  (FARP) 

Refuel  helicopters  for  return  flight  to  ships 

LZ  for  helicopter  fuel  loads 

Decision  Point  (DP) 

Assign  helicopters  to  ships/load 

Key  Distances 

Ships  to  RPs  and  FARP 

RPs  to  LZs 

LZ  to  its  beach 

LZs  to  DP  and  FARP 

FARP  to  DP 

DP  to  Ships 
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3.2  Vertical  Assault  Logic  Flow 

The  following  is  a  description  of  the  top-level  events  that  occur  in  the  AAM  to  simulate  the 
vertical  assault.  These  events  and  their  relationship  to  one  another  are  graphically  depicted  m 
figure  3-1,  which  summarizes  the  AAM  vertical  assault  flowchart.  Figure  3-1  depicts  the  vertical 
assault  in  three  segments:  ship  operations,  the  assault  control  points,  and  the  ingress  to,  unloadmg 
at  and  egress  from  the  landing  zones  and  beaches.  Attrition  due  to  enemy  fire  is  encountered 
in  this  portion  of  the  model.  Ship  operations  consist  jpf  the4nitial  placement  of  hehcopters 
among  the  ships,  assessing  the  heUcopter’s  operational  status,  repairing  inoperable  helicopters, 
and  loading  and  launching  helicopters.  The  ship  operations  arejfurther  descnb^ln  ‘  * 

Loaded  helicopters  leave  the  ships  and  proceed  to  either  a  Rendezvous  Pomt  (RP)  or,  it  the  loaa 
is  fuel,  a  Forward  Arming  and  Refueling  Point  (FARP).  At  the  RP  the  helicopters  are  assembly 
in  waves  before  being  sent  forward  to  the  assigned  LZs.  After  unloadmg  at  the  LZ,  subloads 
proceed  to  their  assigned  beach.  Unloaded  hehcopters  return  to  the  ships  for  the  next  set  of  loads 
by  way  of  the  Decision  Point  (DP).  At  the  DP  the  helicopters  are  assigned  to  a  ^ecific  ship, 
based  upon  available  loads  and  deck  space.  These  assault  control  points  are  described  in  more 
detail  in  figure  3-3.  The  focus  during  the  flight  to,  the  unloading  at,  and  the  flight  from  the  LZs 
is  attrition.  Figure  3-4  describes  these  activities  in  more  depth. 


3-2 


3.2.1  Ship  Operations.  As  figure  3-2  mustrates,  ship  operations  for  a  vertical  assault  starts 
with  an  event  which  initializes  the  status  of  the  heHcopters  with  respect  to  their  location  and 
operational  status.  Once  assigned  a  ship  the  helicopters  can  be  either  inoperable  or  operable. 
If  inoperable,  they  are  sent  below  the  flight  deck  of  the  ship  for  repairs.  If  operable,  they  are 
assigned  to  a  flight  deck  spot  or  moved  below  decks  to  await  a  spot  and  a  load.  On  the  ffight 
deck,  the  initial  set  of  helicopters  are  assumed  to  be  loaded  and  are  ready  to  be  launched.  Other 
operable  helicopters  can  be  initialized  as  airborne  and  in  an  unloaded  state,  and  located  as 
returning  to  the  ships  at  the  DP.  In  fact,  helicopter  reinforcements  can  be  entered  into  the 
simulation  at  a  specified  time  during  the  assault.  All  of  the  airborne,  unload^  helicopt^s  enter 
the  simulation  at  DP.  After  the  initial  set  of  loaded  helicopters  lift  off  the  ships,  they  depart  for 
either  an  RP  or  FARP,  depending  on  their  load.  Ship  operations  consist  of  m^agmg  the  mght 
deck  spots  and  loading  the  next  set  of  helicopters  according  to  the  load  plan  mput  data.  Time 
lines  for  helicopter  repair,  movement  above  and  below  the  flight  deck,  ^d  helicopter  takeoff^ 
landing  are  all  required  input  data.  As  helicopters  arrive  at  the  ship  location  from  the  DP, 
landing  queues  can  be  established.  As  helicopters  depart  the  ship,  flight  deck  spots  b^me 
available  and  helicopters  in  the  landing  queue  can  land.  Helicopters  low  on  fuel  ^e  given  a 
priority  landing  sequence.  Once  on  the  ship,  the  helicopter  is  checked  to  see  if  repair  is  r^^ed. 
If  it  is  inoperable,  or  no  load  is  available,  it  is  moved  below  deck.  Otherwise,  it  is  refueled  and 

loaded. 


Figure  3-2.  A  AM  Ship  Operations  for  a  Vertical  Assault 


3-3 


3.2.2  Assault  Control  Points.  RPs,  FARPs,  and  DPs  are  defined  in  this  document  as  assault 
control  points  because  they  are  instrumental  in  executing  the  assault  plan  and  its  associ^e<noad 
plan.  As  figure  3-3  iUustrates,  the  helicopters  departing  the  ships  fly  to  the  assigned  RP.  ITiere 
may  be  several  RPs  modeled  to  support  a  specific  assault  plan.  At  an  RP,  helicopters  wm 
up  into  their  wayes,  which  results  in  a  queue  caUed  the  "inbound  stack."  There  is  logic  m  AAM 
to  determine  when  a  complete  wave  has  formed  up  and  is  ready  to  depart  for  the  LZ.  There  is 
also  logic  to  push  incomplete  waves  to  the  LZ  before  they  run  short  of  the  fuel 
complete  the  mission.  In  this  way,  an  incomplete  wave  wiU  never  wait  so  long  at  the  ^  that 
they  cannot  go  to  the  LZ  and  then  to  the  FARP:  Heficopters  carrying  fuel  l^ds  proceed  directly 
to  the  FARP.  A  landfeg  queue  can  be  encountered  at  the  FARP  since  unload^  helicopters 
returning  from  their  LZ  can  also  arrive  to  be  refueled.  Helicopters  low  on  fuel  are  given 
Fueling  queues  may  also  be  formed  as  the  number  of  helicopters  increases  at  the  FA^. 
Helicopters  returning  to  the  ships  from  both  LZs  and  the  FARP  go  first  to  the  DP.  The  , 
which  acts  as  a  HeUcopter  Direction  Center  (HDC),  is  where  a  helicopter  is  assigned  next  load 
and  ship.  The  logic  for  assigning  the  next  load  takes  into  consideration  the  type  of  helicopter 
involved  and  its  limitations,  and  then,  the  logic  searches  for  an  eligible  load  with  the  lowest  wave 
assignment.  If  multiple  loads  meet  this  requirement  then  the  load  is  taken  from  the  ship  that  is 
furthest  behind  in  its  unload  plan. 


Decision  Point  (DP) 


Rendezvous  Point  (RP) 


Figure  3-3.  Vertical  Assault  Control  Points 
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3.2.3  LZ  and  Beach  Attrition  Figure  3-4  describes  these  activities  in  depth.  At  the  LZ,  the 
helicopters  are  unloaded.  The  Combat  Power  Index  (CPI),  weight,  and  number  of  personnel  in 
the  load  are  aU  added  to  statistical  counters.  In  the  case  of  a  subload  with  a  speed  greater  than 
zero  (indicating  a  vehicle)  the  counters  are  not  updated  until  the  subload  arrives  at  the  beach. 
Once  a  helicopter  is  done  at  the  LZ,  it  takes  off  to  proceed  to  the  DP/HDC,  or  to  the  FARP  if 
it  needs  to  refuel. 

Attrition  occurs  at  four  points  in  this  section  of  AAM:  the  helicopter’s  ingress  to  the  LZ;  while 
unloadin^t  the  LZ;  the  helicopter’s  egress  from  the  LZ  to  the  DP  or  FARP;  and  the  subload 
can  be  attrited  on  the  way  to  thfe  beach.  The  helicopter  loss  during  ingress  means  the  loads  are 
lost  as  well.  Afhelicopter  loss  at  the  LZ  may  lose  all,  some,  or  none  of  its  loads,  depending  on 
the  unloading  status.  A  "killed"  helicopter  at  the  LZ  has  to  be  pushed  from  the  landing  site, 
which  represents  a  delay  for  other  inbound  helicopters  (LZ  landing  queue).  Subloads  attrited  on 
the  way  to  the  beach  means  the  CPI,  load  weight,  and  personnel  are  lost  and  not  scored. 


Figure  3-4.  Vertical  Assault  Attrition 


3.3  Stochastic  Processes. 


Random  number  draws  are  used  in  AAM  to  determine  if  the  helicopters  are  operational  when 
they  arrive  at  a  ship  (this  includes  the  initial  assignments  at  the  beginning  of  the  simulation  run) 
and  to  determine  if  the  helicopters  and  the  subloads  (vehicles)  survive  their  respective  journeys 
to  the  LZ  and  beach.  The  expected  operational  availability  rates  and  the  attrition  rates  for  each 
stage  of  the  flight  is  required  input  data  for  each  helicopter  type  used  in  the  model.  Similarly, 
attrition  rates  for  each  subload,  or  vehicle,  type  is  required.  -t- 

3.4  AAM  Input  Data 

The  model  requires  the  following  data  in  order  to  be  run.  Note  that  the  entire  landing  plan  ne^s 
to  be  formulated  ahead  of  time  so  that  the  simulation  can  read  it  in  as  a  first  step.  AAM  requires 
five  sets  of  input: 

0  Aircraft  and/or  surface  craft  characteristics,  including  speed,  fuel  consumption,  break 
rates,  repair  times,  operational  ready  rate,  cargo  capacity,  and  refueling  rate 

o  Cargo  characteristics  including  type,  weight,  cube,  composition,  transport  speed,  and 
loading  and  unloading  time;  and  the  type  of  vehicle  that  is  used  to  carry  it 

o  Scenario  information  including  a  geographic  description  of  the  airfields  or 
amphibious  shipping  to  be  used,  distance  to  air-to-air  or  forward  area  refueling 
points,  prioritization  of  cargo  loads,  and  distance  to  landing  zones 

o  Loading  Plan  -  A  detailed  load  plan  is  required  for  each  ship.  The  load  plan  can 
have  a  maximum  of  132  loads  per  ship.  There  are  a  maximum  of  52  possible 
different  load  types,  because  each  load  type  is  designated  by  either  an  upper-case 
or  lower-case  letter.  The  load  plan  for  a  ship  Usts  the  loads  in  sequence  of  desired 
offload  from  the  ship.  The  loads  are  able  to  be  broken  down  into  waves  and  sent 
to  specific  landing  zones  by  the  use  of  character  delimiters,  i.e.,  backslashes  (\)  and 
ampersands  (&).  This  provides  the  modeUer  with  the  ability  to  make  sure  that  aU 
the  ships  conduct  the  offload  in  a  coordinated  fashion,  attempting  to  replicate  the 
landing  plan  of  an  amphibious  assault.  Each  helicopter  will  take  only  one  load  at 
a  time.  The  development  of  the  load  plan  calls  for  a  large  amount  of  work  up  front. 
Every  item  coming  off  the  ships  needs  to  be  organized  into  a  load  type,  then  the 
modeller  has  to  organize  the  loads  so  that  they  are  realistically  placed  on  the 
available  shipping.  The  way  the  loads  are  spread  throughout  the  shipping  will 
impact  how  combat  power  is  built  up  ashore,  and  should  reflect  realistic  combat 
loading  of  amphibious  ships. 


o  Attrition  Rates  -  The  attrition  for  the  helicopters  is  done  based  on  both  the  wave 
currently  being  sent  to  the  LZ  and  the  location  of  the  helicopter.  For  each  wave  of 
the  ship  to  objective  movement,  attrition  data  is  required  for  the  following:  attrition 
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along  the  ingress  route,  attrition  in  the  landing  zone  and  attrition  along  the  ep’ess 
route.  The  first  gate  is  between  the  RP  and  the  LZ.  A  check  is  made  upon  arriving 
at  the  landing  zone  to  see  if  the  helicopter  survived  the  ingress.  The  second  gate 
is  at  the  LZ  as  the  helicopter  unloads.  A  check  is  made  to  see  if  the  helicopter 
survived  during  the  time  needed  to  unload  each  load  in  the  LZ.  If  yes,  then  that 
load  is  added  to  the  forces  already  ashore.  If  the  helicopter  did  not  survive,  then 
each  of  the  loads  remaining  onboard  are  lost  with  the  helicopter.  Each  load 
surviving,  that  has  subloads  with  a  positive  velocity,  represents  a  load  of  at  least  one 
vehicle.  For  ^ch  vehicle,  a  random  draw  is  made  to  see  if  it  survives  the  trip  to 
the  beach.  The  third  gate  is  between  the  LZ  and  the  DP  as  the  helicopter  egresses 
from  the  LZ.  A  check  is  made  to  see  if  the  helicopter  survives  the  egress. 

3.5  AAM  Output  Data 

AAM  calculates  the  time  required  to  move  the  cargo;  the  utilization  rate  of  the  transport  craft, 
fuel  consumption  (including  air-to-air  refueling);  and  the  buildup  of  personnel,  cargo,  and/or 
.  combat  power  at  the  destination  over  time.  AAM  also  provides  as  output,  a  planned  arrival  rate, 
vehicle  by  vehicle,  for  the  entire  operation.  The  time  that  each  aircraft  begins  loading,  finishes 
loading,  arrives  in  the  LZ,  and  completes  off  loading  is  recorded,  along  with  the  load  ^e  that 
it  was  carrying.  This  arrival  schedule  can  be  used  for  planning  purposes  or  to  create  inputs  to 
other  models. 

3.6  Detailed  Assumptions 

AAM  makes  the  following  assumptions; 

o  Ships  do  not  move  or  receive  attrition, 
o  Attrition  is  independent  between  aircraft  and  between  waves. 
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3.7  Limitations 


AAM  has  the  following  limitations: 

o  Modifications  need  to  be  made  to  handle  LCACs  versus  helicopters,  specifically 
well  deck  operations  which  are  serial,  vice  flight  deck  op)erations  which  are 
parallel.  (See  appendix  A.) 

-4“  ^ 

o  The  geometry  of  the  model  is  based  upon  a  network  paradigm.  There  is  no  use 
made  of  grid  coordinates  or  x-y  coordinates.  Instead  the  model  knows  the  distances 
between  all  locations  used  in  the  model.  TTien  using  the  distances  and  known 
speeds  of  entities  acting  in  the  model,  the  model  computes  the  time  needed  to  transit 
from  point  to  point,  and  pushes  the  entities  to  their  next  location. 

o  The  model  makes  use  of  attrition  rates  generated  in  other  models  or  obtained  from 
subject  matter  experts.  For  example,  the  Tactical  Engagement  Model  (TACEM)  has 
been  used  to  generate  attrition  rates,  by  wave,  for  lift  helicopters.  Similarly,  the 
Landing  Assault  Combat  Engagement  Model  (LACEM)  has  been  used  to  obtain 
attrition  rates  for  surface  assault  landing  craft.  However,  AAM  assumes  that  no 
attrition  occurs  outside  the  domain  of  the  supporting  attrition  models,  e.g.,  4,500 
meters  seaward  of  the  high-water  line  on  the  beach  in  LACEM.  The  attrition 
models  referred  to  in  this  example  were  developed  by  BDM. 
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APPENDIX  A 

SURFACE  ASSAULT  MODIFICATIONS 
(19  October  1994  Version  of  AAM) 


A.l  Model  Design 

The  surface  assault  modifications  to  the  model  design  described  in  this  appendix  are  application 
specific  to  the  AAAV/SA.  There  remain  inconsistences  in  the  original  AAM  code  that  prevent 
its  general  use  as  a  surface  assault  model.  Its  use  as  a  surface  assault  model  is  incongruous  with 
its  original  design.  Although  AAM  functioned  adequately  as  a  surface  assault  rifedel  in  the 
AAAV/SA,  it  should  not  have  been  deemed  as  a  robust  surface  assault  model  without  a  major 
redesign  effort  These  modifications  are  described  in  a  table  and  a  series  of  figures  defining  the 
conceptual  logic  flow  of  the  model.  First,  the  "entities"  being  modeled  are  described.  These  are 
the  players  in  the  simulation.  Their  capabilities  to  act  are  defined  by  general  and  unique 
characteristics.  Next,  a  top-level  view  of  the  AAM  conceptual  logic  for  a  surface  assault  is 
presented.  The  next  three  figures  describe  the  conceptual  "engine"  behind  the  model,  i.e.,  these 
figures  describe  how  the  AAM  entities’  actions  and  interactions  are  simulated  and  how  the 
■records  of  the  interaction  outcomes  are  maintained. 

A.2  Entities  Modeled 

Table  A-1  contains  a  list  of  the  major  entities  used  in  the  AAM  for  a  surface  assault  simulation. 
The  purpose  of  this  table  is  to  facilitate  the  discussion  of  the  model  conceptual  logic  flow 
described  in  figures  A-1  through  A-4. 


Table  A-1.  AAM  Surface  Assault  Entities 


Landing  Craft  Types 

Characteristics  of  each 

Status  (e.g.,  availabiiity,  attrition,  etc.) 

Location 

Ships 

Number  of  well  deck  loading  spaces 

Landing  craft  fuel  aboard 

Number  and  types  of  loads 

Loads 

Time  scheduled  to  be  at  the  beach 

Characteristics  (e.g.,  weight,  CPI,  personnel) 
Landing  craft  type  to  carry  load 

Number  of  subloads 

Subloads 

Land  vehicle  characteristics 
(e.g.,  speed,  weight,  CPI,  personnel) 

Rendezvous  Points  (RPs) 

Several  RPs  may  be  defined 

Assembles  assault  wave($)  for  CLZs 

LCAC  Landing  Zones  (CLZs) 

Destination  of  loads  (not  subloads) 

Number  and  size  of  landing  spots 

Each  CLZ  can  have  only  one  beach 

Beaches 

Destination  of  subloads 

Decision  Point  (DP) 

Assign  LCACs  to  ships/load 

Distances 

Ships  to  RPs 

RPs  to  CLZs 

CLZ  to  its  beach 

CLZs  to  DP 

DP  to  Ships 

A.3  Surface  Assault  -  Conceptual  Logic  Flow 


The  following  is  a  description  of  the  key  events  that  occur  in  the  AAM  to  simulate  the  surface 
assault  engagements,  or  interactions.  Figure  A-1  describes  how  the  ttaee  types  of  landing  craft 
that  were  used  in  the  AAAV/SA  were  modeled:  the  Landing  Craft  Air  Cushions  .(LCACs)  wim 
either  swimming  or  nonswimming  subloads,  the  AAAVs,  and  the  AAVs.  The  legend  in  the 
figure  describes  the  arrow  symbols  used  to  trace  the  route  from  the  ships  to  the  beach,  for  each 
type  of  landing  craft,  and  its  subload  as  appropriate.  The  landing  craft  depart  the  ships  at  the 
designated  time,  according  to  the  load  plan,  and  proceed  to  the  RP  to  assemble  m  waves  before 
departing  to  their  designated  CLZs.  Note  that  there  is  no  FARP  in  this  version  ofAe  simulation. 
Three  types  of  LCAC  or  landing  craft  landing  zones  (CLZs)  are  depicted  m  the  one  for 

each  of  the  three  landing  crafts  (LCs)  of  interest  CLZ  type  1  is  where  the  LCACs  dehver  to 
swimming  subloads,  the  AAVs.  EssentiaUy,  CLZ  type  1  becornes  the  Lme  of  Depa^e  ^D) 
for  the  AAVs,  approximately  4.5  Km  from  the  high-water  line  on  the  beach.  The 
transition  from  its  high-speed  configuration  to  its  land  operation  configuration  is  model^  ^  CLZ 
type  2,  with  a  "subload"  that  is  the  same  AAAV  traveling  at  a  slower  speed  to  its  designated 
beach.  The  LCACs  carrying  non-swimmers  to  the  beach,  such  as  the  Bradley  Infantry  Fighting 
Vehicle  or  MlAl  tanks,  proceed  directly  to  CLZ  type  3.  Only  the  LCACs  conto^  m  the 
simulation  by  returning  to  the  ships  for  another  set  of  loads.  They  proceed  from  their  CLZ  type 
3  to  the- DP  for  an  assignment  to  a  ship  for  another  load. 


CLZ  3 


— . •-  LCACs  Delivering  Loads  with  AAVs  to  LOD 

■  •  ■  ■  ■  -  AAV,  AAAV  Slow,  or  AAAV  Fast  Slow  Surrogate.moving  to  the  Beach 
- ►  AAAV  Fast  with  a  Slow  AAAV  Surrogate  as  a  Load 


Figure  A-1.  AAM  Surface  Assault  Flow  Chart 
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A.4  Ship  Operations 


Figure  A-2  depicts  ships  operations  in  support  of  a  surface  assault  The  model  initializes  the 
status  of  the  LC  with  respect  to  their  location  and  operational  status.  The  operational  status  is 
determined  only  at  the  outset  of  the  simulation.  If  an  LC  is  determined  to  be  inoperable,  based 
on  the  operational  availability  numbers  provided  as  input  data  for  that  type  LC,  it  is  essentially 
removed  from  the  simulation.  The  operational  LC  are  assigned  to  spaces  in  the  ship  well  dock 
for  loading  and  remain  operational  throughout  the  remainder  of  the  simulation.  In  the  well  deck, 
the  initial  set  of  LCs  are  assumed  to  be  loaded  and  are  ready  to  depit  the  ship.  The  initial  set 
of  loaded  LCs  depart  the  ships  for  their  assigned  RP.  Ship  operations  consisjt-of  managing  the 
well  deck  spaces  and  loading  the  next  set  of  “tCACs  according  to  the  load  plan,  since  they  are 
the  only  LCs  which  return  to  the  ships  from  the  CLZs.  Time  lines  for  LC  movement  to  and  from 
the  weU  deck,  and  LC  departure  and  landing  at  the  ship,  are  all  required  input  data.  As  LCACs 
arrive  at  the  DP  for  a  ship  assignment,  landing  queues  can  be  established  to  await  well  deck 
space.  Because  weU  deck  spaces  are  serial  in  nature,  Le.,  first  in  is  last  out,  the  DP  assigns  the 
returning  LCACs  to  ships  in  groups  of  one,  two  or  three  LCACs  (according  to  the  capacity  of 
the  weU  deck),  to  minimizes  delays  in  accomplishing  the  loading  plan.  The  next  set  of  LCACs 
enters  the  ship  only  after  the  last  LCAC  in  the  previous  group  has  departed. 


Figure  A-2.  Ship  Operations  for  Surface  Assault 
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A.5.  Surface  Assault  Control 


Only  RPs  and  DPs  are  used  as  control  points  in  the  surface  assault  and  they  are  instrumental  in 
executing  the  assault  plan  and  its  associated  load  plan.  The  FARP  function  is  not  played.  As 
figure  A-3  illustrates,  the  LC  departing  the  ships  proceed  to  their  assigned  1^  at  their  loaded 
speed.  There  may  be  several  RPs  modeled,  to  support  a  specific  assault  plan.  At  an  RP,  the  LCs 
will  form  up  into  waves,  which  results  in  a  queue  called  the  "inbound  stack."  There  is  logic  in 
AAM  to  determine  when  a  complete  wave  has  formed  up  and  is  ready  to  depart  for  the  CLZ. 
Unlikehhe  vertical  assault  case,  only  complete  waves  go  to  the  CLZs.  Only  LCACs  return  to 
the  ships  from^e  LOD  CLZ  and  the  LCAC  CLZ  (see  figure  A-2).  At  the  DP,  which  acts  as 
if  it  were  a  Primary  Control  Ship  (PCS),  the  LCAC  is  assigned  its  next  load  and  ship.  The  logic 
for  assigning  the  next  load  takes  into  consideration  the  priority  of  the  load,  the  number  of  well 
deck  spaces  available,  and  the  load  wave  assignment.  If  multiple  loads  meet  this  requirement, 
then  the  load  is  taken  from  the  ship  that  is  furthest  behind  in  its  unload  plan.  The  DP  assigns 
the  returning  LCACs  to  ships  in  groups  of  one,  two,  or  three  LCACs,  to  minimize  delays  in 
accomplishing  the  loading  plan. 


Figure  A-3.  Surface  Assault  Control  Points 
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A.6  LCAC  Landing  2k)ne  and  Beach  Attrition 


LCAC  Landing  Zone  (CLZ).  At  the  landing  zone,  the  loads  from  the  LCs  are  unloaded.  Then 
the  CPI,  load  weight,  and  number  of  persoimel  in  the  load  are  added  to  the  statistical  counters. 
In  the  case  of  a  subload  with  a  speed  greater  than  zero  (indicating  a  vehicle),  the  counters  are 
not  updated  until  it  reaches  the  beach.  Once  an  LCAC  is  unloaded  at  the  beach,  it  departs  for 
the  DP/PCS. 

Attrition.  Hgure  A-4  depicts  the  surface  assault  attrition.  Attrition  occurs  at  four  poiitts  in  this 
section  of  A  AM:  during  the  LC  ingress  to  the  LZ,  while  unloading  at  the  LZ,  during  the  LCAC 
egress  from  the  LZ  to  the  DP,  and  finally,  during  the  subload+(vehicle)  movement  to  the  beach. 
The  loss  of  an  LC  during  ingress  means  the  loads  are  lost  as  weU.  An  LC  loss  at  an  LZ  may 
lose  all,  some,  or  none  of  its  loads,  depending  on  the  unloading  status.  Subloads  attrited  on  the 
way  to  the  beach  means  that  CPI,  load  weight,  and  personnel  are  lost  and  not  scored. 


Figure  A-4.  Surface  Assault  Attrition 
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AAM  EVENT  NAMES  AND  DESCRIPTIONS 

B2BINP  -  Definition  of  events  and  entities  from  input  file 

HININT  -  Initialization  of  carriers  (either  helicopters  or  landing  craft  or  both) 

HREPR  -  Repair  inoperable  carriers 

FARP  -  Forward  Arming  and  Refueling  Point 

HDCID  -  Decision  Point  (DP)  -  assigns  carriers  to  ships/loads 

HLOAD  -  Load  carriers 

HLNDS  -  Carrier  "lands"  on  ship 

HSSPT  -  Carrier  is  assigned  spot  on  flight  deck  or  space  in  well  deck. 

HTOFS  -  Carrier  departs  the  ship  for  a  rendezvous  point  (RP). 

HBELO  -  If  broken  or  if  there  is  no  load  available,  then  moves  carrier  below  deck.  Returns 
carrier  to  deck  when  repaired  and  load  is  available. 

HRNVO  -  Carrier  arrives  at  RP. 

HLNDL  -  Carrier  "lands"  at  the  LZ 

HULOD  -  Carrier  unloads  at  LZ 

HSEND  -  RP  assembles  a  wave  of  carriers  and  send  to  LZ. 

HPUSH  -  If  carrier  is  killed  at  LZ,  time  is  taken  to  remove  the  carrier  from  the  LZ 

HITBH  -  Subload  moves  to  the  beach. 
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AAM  MODEL 

ENTITY  CHARACTERISTICS  AND  STATE  VARIABLES 


C.l  Helicopter  Types.  ^ 

The  model  has  the  capability  to  simulate  a  number  of  different  type  helicopters.  The  attributes 
describing  the  helicopter  types  are  as  follows;  + 


o  Number  of  helicopters  available  rr-  u  ^  u 

o  Spotting  factor  -  the  amount  of  space  needed  by  the  helicopter  on  the  flight  deck 

o  Speed  when  empty  in  knots 
o  Separation  time  in  minutes  when  landing  full 

o  Separation  time  in  minutes  when  taking  off  full 

o  Mean  time  between  field  repairable  failures  in  minutes 

o  Mean  time  to  repair  field  repairable  failures  in  minutes 

o  Maximum  payload  in  pounds  including  fuel 
o  Maximum  fuel  capacity  in  pounds 
o  Duration  of  scheduled  maintenance 
o  Maximum  time  of  continuous  operations  in  minutes 
o  Initial  availability 

o  Mean  time  between  catastrophic  failures  in  minutes 

o  Mean  time  to  repair  catastrophic  failures  in  minutes 

o  Time  to  configure  aircraft 
o  Time  to  stow  aircraft 

o  Total  number  of  aircraft 

o  Separation  time  when  landing  empty  in  minutes 
o  .  Separation  time  when  taking  off  empty,  in  minutes. 

C.2  Heliconer  Fuel  Usage  Data  Required. 


Usage  data  required  for  helicopter  fuel  is  described  in  the  following  items: 

o  Fuel  used  in  pounds  per  nautical  mile  with  an  internal  load 

0  Fuel  used  in  pounds  per  nautical  mile  with  an  external  load 

o  Fuel  used  in  pounds  per  nautical  mile  with  a  combination  load 
o  Fuel  used  in  pounds  per  nautical  mile  empty 

o  Fuel  used  in  pounds  per  minute  while  hovering  empty 

0  Fuel  used  in  pounds  per  minute  while  hovering  full 

o  Minimum  fuel  reserves  in  pounds 
0  Fuel  safety  factor  multiplier. 


C-2 


C.3  Loads. 


The  loads  to  be  transported  from  the  ships  to  the  LZs/beaches  are  described  by  the  foUowing 
data: 

0  Helicopter  type  that  can  carry  the  load 
o  Time  to  put  total  load  in  carrier,  in  minutes 
0  Time  to  unload,  in  minutes 

0  Load  delivery  method,  either  internal  or  external  or  combination 
0  Rate  of  travel  when  loaded  in  knots 
0  Number  of  people  in  each  load 
0  Combat  Potential  Index  (CPI)  in  load 
o  Weight  of  the  load,  in  pounds 
0  Helicopter  fuel  in  load  (for  FARP) 

o  Desired  pickup  time  (based  on  scheduled  time  to  be  on  beach) 
o  Initial  delay,  earliest  pickup  time 
0  Alternative  helicopter  to  lift  load 

0  Number  of  subloads  in  the  load 

o  Average  speed  of  subload 

o  Attrition  of  subload. 

C.4  Ships. 

Each  ship  is  described  by  the  following  data: 

o  Total  helicopter  spots  on  ship  (flight  deck  and  below  deck) 

0  Flight  deck  operating  spots  on  ship 
o  Initial  LZ  for  load 

0  Ship  group 

o  Time  to  add  a  new  helicopter  from  below  decks  in  minutes 
o  Refueling  rate  in  pounds  per  minute 
o  Minimum  delay  time  on  ship  to  load 
o  Time  to  move  a  new  helicopter  below  deeks,  in  minutes. 

C.5  Landing  Zones. 

Each  landing  zone  is  described  by  the  following  data: 

0  Number  of  LZ  spots 
0  Number  of  RPs  for  this  LZ 

0  Time  to  push  a  broken  helicopter  out  of  the  way,  in  minutes 

o  Landing  number  queue 

0  Number  of  landing  spots  occupied 

o  Landing  time  separation 

0  Time  of  last  assigned  arrival. 


C.6  FARP 


The  FARP  site  is  described  by  the  following  data: 

0  Number  of  helicopters  in  the  FARP 
o  Operating  spots  in  the  FARP 

o  Fuel  available  in  pounds 

0  Refueling  rate  in  pounds  per  minute 
0  Time  to  push  broken  aircraft  out  of  the  FARP 
o  Landing  queue  number 
o  Fuel  queue  number. 
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ACRONYMS  AND  DEFINITIONS 


Acronym 

Definition 

AAAV/SA 

AAM  , 

AAV 

ASP 

Advanced  Amphibious  Assault  Vehicle  Supplemental  Analysis 
Amphibious  Assault  Model 

Amphibious  Assault  Vehicle 

Application  Support  Package 

BDM 

BDM  Federal,  Inc. 

CLZ 

CPI 

LCAC  (or  landing  craft)  Landing  Zone 

Combat  Potential  Index 

DP 

Decision  Point 

EMD 

Engineering  and  Manufacturing  Development 

FARP 

Forward  Arming  and  Refueling  Point 

HDC 

Helicopter  Direction  Center 

IFC 

Infantry  Fighting  Vehicle 

J8 

Joint  Staff 

Km 

Kilometers 

LACEM 

LC 

LCAC 

LOD 

LZ 

Landing  Assault  Combat  Engagement  Model 

Landing  Craft 

Landing  Craft,  Air  Cushion 

Line  of  Departure 

Landing  Zone 

m 

MCCDC 

MLR 

MORS 

meters 

Marine  Corps  Combat  Development  Conamand 

Medium  Lift  Replacement 

Military  Operations  Research  Society 

PCS 

Primary  Control  Ship 

Acronym 


Definition 


RP 

SIMTAX 

TACEM 


Rendezvous  Point 
Simulation  Taxonomy 
Tactical  Engagement  Model 


V&V 


Verification  and  Validation 


